Run tests on Windows 2022/2025 and gate X25519 support - #5

Human Summary

Adds a test matrix to start running tests under Windows Server 2025. This exposed an issue with X25519 in 2025 that seems to be a regression on the Windows side, since a previously-valid Wycheproof assertion begins to fail. I'm admittedly out of my depth here so rather than trying to fix anything, we conditionally disable support for X25519 if we detect this particular regression. Should be easy to revisit in the future if we want to re-enable X25519 on 2025.

Note that this does not affect FIPS builds as X25519 is disabled on FIPS in any case.

Summary

• Run the Test job on both windows-2022 and windows-2025 using a non-fail-fast matrix.
• Detect whether the host CNG implementation can import a valid X25519 edge-case public key before advertising X25519 in the default provider.
• Keep X25519 available through the exported group symbol/custom providers, but skip default advertisement and explicit X25519 integration cases on hosts where CNG rejects the probe.
• Relax the ECDSA Wycheproof Shamir edge-case test to tolerate the observed CNG version difference for valid signatures while still requiring invalid signatures to fail.

Context

Windows Server 2025 CNG rejects the valid X25519 Wycheproof u = 4 public key at BCryptImportKeyPair with STATUS_INVALID_PARAMETER, even when represented with a valid Montgomery v coordinate. Windows Server 2022 accepts the same vector. Since a backend that rejects this valid X25519 input can fail TLS negotiation for valid peer key shares, the default provider now advertises X25519 only when the runtime CNG probe succeeds.

Verification

• cargo fmt -- --check
• make check-licenses
• GitHub Actions matrix:
  • Test (windows-2022) passed
  • Test (windows-2025) passed
  • Lint passed
  • Coverage passed
  • license checks passed